The present invention relates generally to process control systems and, more particularly, to the automatic detection, analysis, and correction of problems existing within function blocks, devices and loops of a process control system.
Process control systems, like those used in chemical, petroleum or other processes, typically include a centralized process controller communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine and then generates control signals which are sent over the buses to the field devices to control the operation of the process. Information from the field devices and the controller is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.
In the past, conventional field devices were used to send and receive analog (e.g., 4 to 20 milliamp) signals to and from the process controller via an analog bus or analog lines. These 4 to 20 ma signals were limited in nature in that they were indicative of measurements made by the device or of control signals generated by the controller required to.control the operation of the device. However, in the past decade or so, smart field devices including a microprocessor and a memory have become prevalent in the process control industry. In addition to performing a primary function within the process, smart field devices store data pertaining to the device, communicate with the controller and/or other devices in a digital or combined digital and analog format, and perform secondary tasks such as self-calibration, identification, diagnostics, etc. A number of standard and open smart device communication protocols such as the HART(copyright), PROFIBUS(copyright), WORLDFIP(copyright), Device-Net(copyright), and CAN protocols, have been developed to enable smart field devices made by different manufacturers to be used together within the same process control network.
Moreover, there has been a move within the process control industry to decentralize process control functions. For example, the all-digital, two-wire bus protocol promulgated by the Fieldbus Foundation, known as the FOUNDATION(trademark) Fieldbus (hereinafter xe2x80x9cFieldbusxe2x80x9d) protocol uses function blocks located in different field devices to perform control operations previously performed within a centralized controller. In particular, each Fieldbus field device is capable of including and executing one or more function blocks, each of which receives inputs from and/or provides outputs to other function blocks (either within the same device or within different devices), and performs some process control operation, such as measuring or detecting a process parameter, controlling a device or performing a control operation, such as implementing a proportional-derivative-integral (PID) control routine. The different function blocks within a process control system are configured to communicate with each other (e.g., over a bus) to form one or more process control loops, the individual operations of which are spread throughout the process and are, thus, decentralized.
With the advent of smart field devices, it is more important than ever to be able to quickly diagnose and correct problems that occur within a process control system, as the failure to detect and correct poorly performing loops and devices leads to sub-optimal performance of the process, which can be costly in terms of both the quality and the quantity of the product being produced. Many smart devices currently include self-diagnostic and/or calibration routines that can be used to detect and correct problems within the device. For example, the FieldVue and ValveLink devices made by Fisher Controls International Inc. have diagnostic capabilities that can be used to detect certain problems within those devices and also have calibration procedures that can be used to correct problems, once detected. However, an operator must suspect that a problem exists with the device before he or she is likely to use such diagnostic or calibration features of the devices. There are also other process control tools, such as auto-tuners that can be used to correct poorly tuned loops within a process control network. Again, however, it is necessary to identify a poorly operating loop before such auto-tuners can be used effectively. Similarly, there are other, more complex, diagnostic tools, such as expert systems, correlation analysis tools, spectrum analysis tools, neural networks, etc. which use process data collected for a device or a loop to detect problems therein. Unfortunately, these tools are data intensive and it is practically impossible to collect and store all of the high speed data required to implement such tools on each process control device or loop of a process control system in any kind of systematic manner. Thus, again, it is necessary to identify a problem loop or a device before being able to effectively use these tools.
Still further, each device or function block within a smart process control network typically detects major errors that occur therein and sends a signal, such as an alarm or an event, to notify a controller or a host device that an error or some other problem has occurred. However, the occurrence of these alarms or events does not necessarily indicate a long-term problem with the device or loop that must be corrected, because these alarms or events may be generated in response to (or be caused by) other factors that were not a result of a poorly performing device or loop. Thus, the fact that a device or a function block within a loop generates an alarm or event does not necessarily mean that the device or loop has a problem that needs to be corrected. On the other hand, many devices can have problems without the problem rising to the level of severity to be detected as an alarm or an event.
To initially detect problems within the process control system, a process control operator or technician generally has to perform a manual review of data generated within a process control system (such as alarms and events, as well as other device and loop data) to identify which devices or loops are operating sub-optimally or are improperly tuned. This manual review requires the operator to have a great deal of expertise in detecting problems based on raw data and, even with such expertise, the task can be time-consuming at best and overwhelming at worst. For example, an instrumentation department of even a medium-sized operating plant may include between 3,000 and 6,000 field devices such as valves and transmitters. In such an environment, the instrument technician or control engineer responsible for a process area simply does not have the time to review the operation of all the field device instrumentation and control loops to detect which loops or devices may not be operating properly or may have some problem therein. In fact, because of limited manpower, the only devices usually scheduled for maintenance are those that have degraded to the point that they dramatically impact the quantity or quality of the product being produced. As a result, other devices or loops which need to be returned or which otherwise have a problem therein that could be corrected using the tools at hand are not corrected, leading to the overall degraded performance of the process control system.
Even after the under-performing devices and control loops are identified and the necessary diagnostics, tuners and other tools are available to further analyze and correct the problem, the user must possess the requisite knowledge and experience to select the appropriate tool and to use the tool correctly to resolve the problem. In some cases, the user may not have sufficient technical knowledge or practical experience to resolve the problem. Despite having tools available which display problems in the process control system and which recommend further diagnostic tools and remedial measures, the user may need further assistance to effectively monitor the process and correct problems.
In order to effectively monitor the process control network, the user must be knowledgeable about the process, the field devices, and the tools available to diagnose and correct problems in the process control network. Even if the user is familiar with the field devices and the tools, the user may not have ready access to all of the relevant data, such as event data, trending data, historical change and maintenance data for the device and process, and the like. Moreover, the user at the operator workstation is not typically an expert on the processes and the field devices. As a result, even though the system may provide some information regarding under-performing field devices and control loops, and suggest tools to diagnose and correct problems, there may still be an overwhelming amount of relevant information to evaluate in order to identify the source of the problems and to implement the measures necessary to correct the problem.
A diagnostic system for use in a process control system collects and stores data pertaining to the operation of the process control system in a database, and uses an expert engine to apply rules for analysis to the information in the database to determine solutions to problems in the process control system. The database stores various types of information that are relevant to determining both the source of the problems detected in the process control system and the steps necessary to either further analyze or correct the detected problems. The information in the database includes data pertaining specifically to the detected problem and to the field device, function block or control loop in which the detected problem exists. The database may also store event and alarm data, such as notices of scheduled maintenance and changes to operating parameters, that is relevant to identifying the source of the problem and to identifying the appropriate analytical and remedial measures. The database may also contain historical data related to previous changes to the process control system to correct previously detected problems.
When a problem is detected, the expert engine applies the rules for analysis to the relevant data in the database. As part of the analysis, the rules may dictate that the expert engine invoke additional analysis applications that are available on the process control network. The analysis applications may include tuners, calibrators, diagnostics tools, or any other applications that may be useful in analyzing and/or correcting the detected problem.
The diagnostic system may further include a user interface to which information is transmitted by the expert engine to notify the user of the detected problem. The expert engine may also transmit additional information, if available, regarding recommended courses of action to further analyze and/or correct the detected problem. For example, the expert engine may recommend the use of a further diagnostic tool to pinpoint the source of the detected problem. Alternatively, the expert engine may provide a recommendation to modify the process control system, such as changing the value of a parameter or changing the logic in a control loop. If requested to do so, the expert engine may also execute the recommended tools or guide the user through the steps necessary to implement a recommended change.
In this manner, the diagnostic system uses all the available relevant information to analyze the detected problem and to arrive at a recommended solution to the problem. The expert engine preferably runs continuously in the background to address problems as they arise, but may also be initiated by a user, a triggering event or an automatic scheduler so that the problems are addressed in an efficient manner. The operation of the expert engine saves time on the part of the user and does not require the user to have a great deal of expertise in solving problems in control loops and devices. Moreover, the diagnostic system is able to accumulate and analyze all the data that is relevant to solving the detected problem more quickly and efficiently. Besides saving time, the diagnostic system reduces the burden on the user and helps assure that the proper diagnostics tools and remedial measures are used in each circumstance and that these tools are implemented correctly.